fixes #92

The problem causing the issue above is that Xvfb started to be a lot more chatty. Using it with chrome it keeps outputing the following on each connection:

1 XSELINUXs still allocated at reset
SCREEN: 0 objects of 304 bytes = 0 total bytes 0 private allocs
DEVICE: 0 objects of 88 bytes = 0 total bytes 0 private allocs
CLIENT: 0 objects of 136 bytes = 0 total bytes 0 private allocs
WINDOW: 0 objects of 48 bytes = 0 total bytes 0 private allocs
PIXMAP: 0 objects of 16 bytes = 0 total bytes 0 private allocs
GC: 0 objects of 16 bytes = 0 total bytes 0 private allocs
CURSOR: 1 objects of 8 bytes = 8 total bytes 0 private allocs
TOTAL: 1 objects, 8 bytes, 0 allocs
1 CURSORs still allocated at reset
CURSOR: 1 objects of 8 bytes = 8 total bytes 0 private allocs
TOTAL: 1 objects, 8 bytes, 0 allocs
1 CURSOR_BITSs still allocated at reset
TOTAL: 0 objects, 0 bytes, 0 allocs

So there is a lot of data going through stderr if we make a lot of connection to the display. And currently the library assigns stdout and stderr to a subprocess PIPE but doesn't read from it until it stops it. Hence all this data is buffered and when the buffer is full it hangs the execution of the whole program.

I am not sure if what I propose is the best solution but it seems that the PIPEs aren't actually used, only to debug log everything at the end. Another solution could be to (optionally?) redirect stdout/stderr to a log file if we want to keep the debug data. Would be neat if we could redirect to a logger directly but unfortunately I don't think it is really possible in python.